feat(github): protect vaulted tags against deletion and force-push - #7

The README's first promise is that uvault "pushes them as immutable tags",
but nothing made them immutable: a tag can be deleted or force-moved by
anyone with push access to the vault, which is the same failure mode
vaulting exists to prevent, just relocated from upstream to the vault.

Adds `GitHubForge.ensure_tag_ruleset(repo_path)`, which applies a tag
ruleset blocking `deletion` and `non_fast_forward`, and calls it after a
successful fork.

Deliberately takes a repository path rather than deriving one from the
source, so the same primitive serves a per-upstream fork and a single
shared vault repository. That keeps it useful whichever topology the
discussion in petrus-v#6 settles on, and it is the piece a `protect-tags`
subcommand would reuse unchanged.

Three properties that matter, each with a test:

- **`creation` is never blocked.** It is the obvious third rule and it
  would break every later sync, because the vault has to keep accepting
  new tags. Only `deletion` and `non_fast_forward`.
- **It never raises.** Creating a ruleset needs `Administration: write`,
  strictly more than forking and pushing, so a token that cannot do it
  must still be able to vault. 403 and 404 get specific messages -- 404
  being what a plan without rulesets looks like -- and anything else is
  warned about and swallowed. `fork()` therefore still succeeds when the
  tags cannot be protected.
- **It is idempotent.** An existing ruleset with the same name and target
  is left alone, so re-running costs one GET.

Coverage stays at 100% in the gating `--extra github` run.

Review found that `non_fast_forward` alone does not make a tag immutable:
force-pushing over an existing tag still succeeded. Tested on a real
repository, the `update` restriction is what prevents it, so the ruleset
now carries `deletion`, `non_fast_forward` and `update`.

Blocking updates costs nothing here. uvault pushes
`<sha>:refs/tags/<tag>` with no `+` refspec and no `--force` (vcs.py
`vault_tag` / `vault_release_tag`), so it never moves a tag that already
exists. `creation` remains deliberately unrestricted -- that one really
would break every later sync.

Also adds the requested reference documentation under `uvault sync`,
next to the existing automatic-forking section: what the ruleset is
called, which three rules it applies and why, that creation is left
alone, and that the whole thing is advisory -- a token without
`Administration: write` still vaults, with a warning. Notes the two cases
that surprise people: rulesets need a public repository on GitHub Free,
and repositories forked before this existed are not retrofitted.